前言

傳統的 client-server 驗證模型，用戶透過憑證（ex. 帳號、密碼）去訪問其存放在伺服器的資源，但隨著分散式網路服務（distributed web services）以及雲端運算（cloud computing）的廣泛應用，越來越多的第三方應用程式（third-party applications）需要訪問由其他伺服器或服務託管的資源，於是 OAuth 1.0 以及後來的 OAuth 2.0 等協定就隨之出現，目的就是為了解決這些需求，那我們就來看一下 OAuth 是什麼吧！

什麼是分散式網路服務跟雲端運算？

• 分散式網路服務（Distributed Web Services）：與傳統的集中式系統不同，集中式系統的所有資料和請求處理均由一個中心伺服器進行管理。分散式網路服務則將系統劃分為多個獨立的節點，每個節點都有能力獨立處理不同的請求。此外，用戶的資料也會被安全地分散儲存在多個位置，這樣不僅提高了系統的效能和可靠性，也增強了資料的安全性和可擴展性。

• 雲端運算（Cloud Computing）：雲端運算是一種通過網路提供運算資源的方式，像是儲存空間和基礎設施，使用者可以根據自己的需求來選擇。這樣一來，個人和企業就不需要自己管理實體的硬體設備，使用雲端服務的好處是可以根據實際使用量來付費，讓資源的管理變得更加簡單和靈活。例如：公司使用 AWS 的服務，當網路流量增加時，公司可以動態的增加伺服器數量以及空間，當流量減少時也可以動態的減少，可以避免管理硬體資源的成本。

OAuth 1.0 是什麼？

OAuth，全文為 open authorization，是一個開放的授權標準，允許第三方應用程式在不需要共享憑證（帳號、密碼等）的情況下，訪問用戶在其他網站儲存的資源。

在RFC 5849被規範的 OAuth 1.0 ， 有別於傳統的 client-server模式，定義了以下三個角色：

1. client：一個能夠發出 OAuth 身份驗證請求的 HTTP 用戶端。
2. server：一個能夠接受 OAuth 身份驗證請求的 HTTP 伺服器。
3. resource owner：能夠通過使用憑證向伺服器進行身份驗證來訪問和控制受保護資源的實體。
   直接看定義可能會有點霧煞煞，所以讓我們來想像以下的場景來幫助理解：

小明習慣將他的照片都上傳到 google drive 上面，今天他覺得自己 facebook 的大頭貼看得很膩，想要換一張新的照片，於是他就直接在 facebook 中選擇取用 google drive 的照片，就不用再到 google drive 下載到電腦再上傳到 facebook 了！

在上面的情景中，小明就是那個 resource owner ，而 facebook 就是 client，server 則是 google drive 的伺服器。

流程又是如何運作？

主要分成以下步驟：

1. facebook 在事先就會先註冊 google drive 的客戶端憑證，包括用戶端的識別碼以及共享密鑰

2. 然後在小明按下選擇取用 google drive 的照片時， facebook 會先向 google drive 請求一組臨時憑證，請求如下：

   POST /initiate HTTP/1.1
   Host: googledrive.com
   Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Ffacebook.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
   

3. google drive 收到請求後回傳以下臨時憑證：

   HTTP/1.1 200 OK
   Content-Type: application/x-www-form-urlencoded
   oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&
   oauth_callback_confirmed=true
   

4. facebook 會將小明的瀏覽器重定向到 google drive 的授權頁面，讓小明給予 facebook 存取他在google drive 照片的權限

   https://googledrive.com/authorize?oauth_token=hh5s93j4hdidpola
   

5. 在小明成功授權之後，瀏覽器會被重新定向到上面 facebook 請求中的 callback URI，並通知 facebook 已經完成授權

   http://facebook.com/ready?
   oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884
   

6. facebook 收到通知後，透過臨時憑證向 google drive 請求一組 token 憑證：

   POST /token HTTP/1.1
   Host: googledrive.com
   Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_token="hh5s93j4hdidpola",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131201",
   oauth_nonce="walatlh",
   oauth_verifier="hfdp7dh39dks9884",
   oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"
   

7. google drive 驗證請求後，將 token 憑證回傳給 facebook

   HTTP/1.1 200 OK
   Content-Type: application/x-www-form-urlencoded
   oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
   

8. facebook 收到後，就可以將臨時憑證以及 token 憑證放在請求中向 google drive 要求存取照片了！

   GET /photos?file=vacation.jpg&size=original HTTP/1.1
   Host: googledrive.com
   Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_token="nnch734d00sl2jdk",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131202",
   oauth_nonce="chapoH",
   oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
   

小結

今天介紹了關於 OAuth 出現的背景，以及 OAuth 1.0 的流程是如何運行，不過由於一些原因，導致現在主流都已經偏向 OAuth 2.0 ，至於原因以及這兩個版本之間的差異，就留到明天繼續吧！

參考資料

RFC 5849
What is OAuth really all about - OAuth tutorial - Java Brains